I have just read an interesting post by Ted Ts’O about copyright protection on the net [1]. Ted is well known as a free software programmer, but it’s slightly less well known that he is an avid Science-Fiction fan. In the Free Software community most people seem to be interested in Sci-Fi, but Ted is more interested than most. Ted’s post concerns the irresponsible actions of the Science Fiction and Fantasy Writers of America [2] (SFWA). To summarise it they issued DMCA [3] take-down notices for any web page that matched a search on the names “Asimov” or “Silverberg“. I don’t approve of the DMCA laws as a collection, but take-down notices are not necessarily bad (I have issued such notices for unauthorised copies of my own work in the past). The problem in this case is that the words in question are extremely common, not only might they be used as the names for other people (authors or characters) but Asimov in particular is a well known term when describing the potential development of intelligent computers that operate robots (see the Three Laws of Robotics [4]), the term “not Asimov Compliant” has been used by Alastair Reynolds in Century Rain to refer to a class of military robots that have no compunction about killing humans. Among the fall-out of the SFWA actions was the removal of a free novel by Cory Doctorow [4]. Incidentally my favourite free to download Cory Doctorow book is Eastern Standard Tribe [5]. craphound.com has Cory’s blog as well as links to other free Sci-Fi that he’s written. Reading the links from Ted’s post took me to a blog entry by the current SFWA vice-president [6] which describes authors such as Cory Doctorow as “webscabs“. This offends me greatly. My work and that of my friends in writing free software could be described in the same way (and in fact is described in a similar way by some software monopolists). Every blogger could have their work described in a similar way by paid journalists. The fact that the SFWA VP is not representing SFWA when writing such comments does little to allay concern about this. It seems to me that people with such ideas are intent on attacking my community, and that it would be wrong of me to give any of them $0.50 by buying one of their books. I resolve to not buy any more Sci-Fi books until I have read all the freely available books that I want to read. After that I will prioritise my book purchases with a significant factor being how well the author gets the concepts of copyright etc. If nothing else an author who can’t understand how copyright (something that is essential to their own livelyhood) interacts with current computer systems will have significant difficulties in predicting how technology and society will develop over the next hundred or thousand years. My problem in reading Sci-Fi books is not in discovering books that are enjoyable and which contain interesting concepts, but in finding time to read them. Thanks to SFWA for giving me an extra criteria to cull the list of books to read.

• [1] http://thunk.org/tytso/blog/2007/09/15/whack-the-gopher/


• [2] http://www.sfwa.org/


• [3] http://en.wikipedia.org/wiki/Dmca


• [4] http://www.boingboing.net/2007/08/30/science-fiction-writ-1.html


• [5] http://craphound.com/est/


• [6] http://community.livejournal.com/sfwa/10039.html

Share This

I recently came across three very well written and very thoughtful blog postings by Rick Cook (author of the Wiz Zumwalt Wizardry series):

1. Copyrights, Whack-the-Gopher, and SFWA — Why I Quit
2. The Economics of Theft: Son of Whack the Gopher
3. WHACK THE GOPHER III: The Return of the Mutant Grandson

The incident which kicked off these postings was an informal DMCA takedown notice posted by the Vice President of the Science Fiction Writers of America, Dr. Andrew Burt which was created by a process only slightly more sophisticated than using word search for “Asimov” and “Silverberg”. Unfortunately, this takedown notice erroneously included a junior high school teacher’s list of 300+ recommended books (which naturally contained the strings “Issac Asimov” and “Robert Silverberg”, an on-line published science-fiction magazine that referenced the science fiction author Isaac Asimov in a review, and a creative-commons licensed science fiction novel which had been deliberately published on the web for free distribution, and for which the author had explicitly forbidden the SFWA from taking any action on behalf of his books. The entire incident was wonderfully filled with irony — from the fact that an organization of writers who purport to write about what the future might bring given scientific and technological advances could so totally fail to get the Internet or understand that such a campaign might cause them to alienate their readers and fan base, to the the fact that Doctor Andrew Burt, Ph.D. is a professor in computer science at the University of Denver with a research interest in copyright and electronic piracy, could so incompetently foul up a DMCA takedown request and not understand that “grep” might result in false positives that would require human checking (”Andrew? Your alma mater is calling; they would like their degree back…”) One good thing that has come out of this whole mess is that it has been, as junior high school teacher Nick Singer put it, “a teachable moment”, and an opportunity for people to reflect about issues of copyright, the rights of authors, ebooks, and the Internet. This is a hard problem; I very strongly believe that (at the same time) “Art wants to be free; Artists want to be paid” (to use a phrased coined by a friend of mine, Jesse Vincent (blog here), to the point that I’ve been willing to put my money where my mouth is. So far the solutions for achieving this are nowhere near perfect, but they are certainly better than sending out shotgun DMCA takedown requests. In any case, Rick Cook’s thoughts on the subject are a worthy contribution to the subject. He says he’s going to do one more article on his blog proposing an economic solution to this problem; I can’t wait to see what he has to say on the subject.

Because I’ve been getting a little frustrated with the lack of trackback support, prohibition against Javascript, etc. I’ve decided to set up a Wordpress installation on my private machine. For now, I have things set up so that posts made on my Wordpress blog will get mirrored onto my LiveJournal account. I may do some friends-locked posts still on LJ, but my general philosophy is to not post anything I might consider private on a blog, friends-locked or no. So we’ll see how often I make use of that option.

Because I’ve been getting a little frustrated with the lack of trackback support, prohibition against Javascript, etc. I’ve decided to set up a Wordpress installation on my private machine. For now, I have things set up so that posts made on my Wordpress blog will get mirrored onto my LiveJournal account. I may do some friends-locked posts still on LJ, but my general philosophy is to not post anything I might consider private on a blog, friends-locked or no. So we’ll see how often I make use of that option. Originally published at Thoughts by Ted. Please leave any comments there.

Recently, Josh Berkus blogged about The Myth of the Benevolent Dictator. In it he complained about people who try to posit that a benevolent dictator was "an unalloyed asset" to their project, and that there were many successful and valid forms project governance other than the singleton project leader. Furthermore, he argues that the best way is to form a community, and then ends by suggesting that people who say "dictatorship good" is really saying "democracy bad", and perhaps the motives of the person using that argument should be questioned.

Given that I was one of the first people (and probably the first person) to use that phrase to describe Linus's governance model, obviously I feet the need to respond to his thoughts on the matter.

First of all, the term "benevolent dictator" comes from an old saying, "the best form of government is the benevolent dictator --- there's only one problem, finding the benevolent dictator"[1]. And in my presentations where I explained the Linux project management model, I was always careful to say that there were other models that were used by other projects, and that it was interesting to study why certain management models worked for some projects but not others.

So by definition, if a project is successful with a single project leader ultimately responsible for making decisions to settle conflicts, then that leader is a "benevolent dictator"; if they aren't successful, then that would be an example of a dictator who wasn't able to be "benevolent", eh? :-)

In all seriousness, though, I agree with Josh when he says that the key part of an open source project being successful is gathering together a healthy community. But let's unpack that a little. In order for a community to be healthy, there needs to be general consensus on the values and cultural norms for that community. So for example, in the case of Debian, which Josh holds up as a successful community, not everyone has the ability to vote; you have to pass a fairly stringent process which tests your technical skills and your willingness to subscribe to Debian's core values as embedded to the Debian Social Contract. People who do not pass the New Membership process do not have the right to vote in Debian, even if they are the most rabid, fanatical users of Debian.

This brings up a key point about governance analogies; they all don't map cleanly into the real world for two closely related and extremely important reasons: (1) No one has a fundamental human right to be a member in some OSS project, and (2) No one is forced to stay in a particular OSS project. These are really two sides of the same coin, and what it means is that, as in Debian, "democracy" does not mean that everyone is entitled to political franchise, or the right to vote, and in a project which has a "benevolent dictator", the powers of the dictator is fundamentally limited by the simple fact that if he is too unreasonable, people are always free to leave or fork the project. These differences are extremely important when trying to reason about "democracy" or "dictatorship" as being good or bad as applied to open source projects.

Democracy is rarely the best way for an open source project to make decisions. For technical issues, you want the right answer, and majority vote isn't necessarily way to resolve a technical issue. As far as policy decisions, if the decision can not be made by consensus, then some percentage of the community will be unhappy with how the decision, and that can cause a huge amount of arguments and dissension. If the community has very clearly expressed values, then the number of times where such votes need to be made will be minimal.

For example, Debian has an explicit declaration of its values and mission in its Debian Social Contract; people who don't agree to the Social Contract aren't allowed to become Debian Developers and thus are not allowed to vote. But, one of the more controversial disputes that have threatened to tear apart Debian is the question of the non-free packages, and that's fundamentally because of an ambiguity in the Social Contract. On the one hand, Debian has declared that it is fundamentally 100% about Free Software, to the extent that it has adopted Richard Stallman's rather petulant request that the Linux operating system be called GNU/Linux (which admittedly is better than Lignux.) On the other hand, the Social Contract also explicitly specifies the existent of the non-free section in the distribution. Over time, this ambiguity have been the source of a lot of highly passionate debate and controversial votes that have satisfied neither the FSF fanatics nor the more Linux-like moderate position tolerating the use of proprietary as well as open source software. I submit that if Debian had either explicitly stated an FSF-centric position, and only accepted members that supported point of view, or explicitly subscribed to a position that users should be able to use whatever software they feel meets their needs, as Ubuntu has, it would avoided many arguments that have threatened to tear apart Debian.

More recently the fact that the Social Contract has been silent about whether or not Debian Developers should be paid or purely be 100% volunteer. This was never an issue in the Linux Kernel community, but for some reason it has been a highly divisive and disruptive issue inside Debian. Democratic votes have not really resolved the conflicts, and in fact some might claim that these votes have if anything hardened various Debian Developers' positions.

Going back to Josh's final point, "Next time you hear the words 'benevolent dictator' you probably want to think about the motives of the person saying it. Because the corollary to 'dictator good' is 'democracy bad', and is that a place you really want to go?", I am quite proud to stand by my convictions that for Open Source Projects, pure democracy is a bad idea. If a projects wants to be technically successful, it needs to be a meritocracy, and chose the best technical decisions; Linus does not decide by abiding with majority vote whether or not a patch should be accepted, and that's as it should be.

Even Debian's "raw democracy" doesn't let any random luser get to vote on who should be the Debian Project Leader. Decisions need to be made by people who are competent to make a valid choice. Even in real life, one could argue that the choice made by Americans, over of which 70% believed that Saddam Hussein was "very likely" or "somewhat likely" to be personally involved with the 9/11 attacks even though there has been absolutely no evidence to support this "gut feeling", made a rather disastrous choice in voting to re-elect George Bush to the presidency. Democracy without sufficient education, literacy, and intellectual curiosity to learn about what is happening in the world can result in truly disastrous choices being made. So certainly, democracy is not a panacea. In the real world, it may be the best choice of many bad choices, given how much people have suffered under military dictatorships. However, in the Open Source world, things are different because people are always free to leave one project and affiliate with another --- not an alternative most people living in dictatorships have historically had. Given these key differences, I think it is clear that for open source projects, democracy is indeed often a bad idea, and that if you if a project has a single person with a strong technical vision and good interpersonal skills, the benevolent dictator model can indeed be a very viable and successful.

Does that mean that other forms of governance can't work? Of course not! The rotating dictatorship used by Perl[2], the core-team-with-strongarm leader used by OpenBSD, the corporate dominated scheme of MySQL, the self-selecting core team model of Samba, all are successful models. I just have to strongly disagree with Josh's claim the single strong leader approach is somehow inferior to "democracy" as if democracy was somehow a magic bullet.


[1] For am early example of this quote, nine years ago, please see this message, where I'm pretty sure I authored the colon prefixed quote, and I know I was using the term "benevolent dictator" much earlier than 1998.

[2] In the early days of Perl, it also used the benevolent dictator model. Larry Wall is a great exemplar of how someone who has a strong vision of what he wanted to accomplish, and was humble and easy to work with, both on-line and in person, can make all the difference in the world for an up-and-coming open source project.

I looked at the Foleo and played with one while I was at Linux World a few weeks ago, but it is so restrictive in what it can do that I was completely unimpressed. First of all, according to one of the people at the booth, it will only work with a select set of Treo's; mostly the newer ones. A colleague I was with had just gotten a Treo 650, and the person at the booth said that it wouldn't work with that model of Treo. (WTF?) Furthermore, it will only do e-mail (POP or IMAP) by linking with the Treo over bluetooth connection and letting the Treo pull down the e-mail and store it on the Treo. Given that it only has 128 megs of RAM and 256 megs of Flash, it just doesn't have enough storage apparently to run a stand-alone e-mail application, which is a little bit scary. The limited amount of memory is probably why it is using Opera as a web browser, which previous experience on the N800 has largely unimpressed me in terms of compatibility with Web 2.0 sites that aggressively use AJAX or flash. So OK, it's not supposed to be a laptop. But the problem is, for 0.2 pounds more, I can get a laptop. Let's review the critical statistics, shall we? The Foleo costs $499, weighs 2.5 pounds, and has a size of 10.5" by 6.7" by 0.9". As stated before it has 128 megs of RAM and 256 megs of flash, with a SD slot for expansion purposes, and it has a claimed 5-6 hours of battery life. But let's compare that with my IBM X41 which I recently purchased off of eBay for $800. It has 1.5 gigs of memory, and 60 gigs of hard disk. It has two batteries; with the 4 cell battery it weighs 2.7 pounds and delivers 2 hours of battery life, and with the 8 cell battery it weighs 3.2 pounds and delivers 4 hours of battery life. So true, even with the 8 cell battery the X41 is 1.7 pounds heavier and still has slightly less battery life. But you can do a lot more with the X41! Furthermore, the Foleo's weight advantage is somewhat nullified by the fact that you have to bring the Treo around to do certain activities, and the Treo has to be powered on since the Foleo is mostly designed around being a remote large screen for the Treo. At the end of the day it's all about tradeoffs. Perhaps if enough companies created enough killer apps that could fit in 128 meg of ram for the Foleo, it might be useful enough to justifying buying it. I hear for example, that even though the Foleo doesn't have any kind of PIM functionality, a 3rd party ISV is planning on making a product available that will provide calendar and contact functionality that can sync Palm PDA's. No word on how much it will cost or how usable it will be, but with enough applications, maybe Foleo could be useful enough to justify its size/weight. I imagine that these apps will probably be commercial ones, since open source apps like Evolution will probably have difficulty fitting in the Foleo's constrained environment. :-) And, of course, it's a lot cheaper than my used X41 laptop, never mind a brand-new Lenovo X61s, which could run 2 or 3 kilobucks fully outfitted with the 4 gigs of memory and 160 gig/7200 rpm drive. However, as a road warrior, my priorities are not just weight, but functionality. A 2.5 pound solid-state laptop with only 128 megs of memory which massively restricts what I can do is not a good use of the space in my laptop bag. What I'm waiting for is the next generation of the Thinkpad X series which has a solid state disk --- which shouldn't be that far off --- and the elimination of the spinning magnetic media would mean that we should have something with Foleo's battery life without the Foleo's limited usefulness. Sure, maybe I will need to wait another year or two for my perfect laptop (12", 1024x768 LED display, at least 60 gigs solid state disk, at least 2-4 gigs memory, Intel core 2 or follow-on processor, < 3 pounds, > 5 hours useful lifetime) to become available, but the technology to do this exists today; it's just a matter of making it affordable. But given that kind of long-term future, I'm willing to settle for now with either 2 or 4 hour battery life, and a slightly heavier laptop, than to use something today with a desperately slow ARM processor and only 128 megs of memory. The weight/size savings and the increased battery life of the Foleo isn't a fair tradeoff given its very limited capabilities. This is all really too bad, because if Palm is counting on the Foleo to allow it to succeed, I think the concept has some massive shortcomings, much like their claimed LifeDrive product, which didn't last very long. And I really like the Palm company; I still haven't found better PDA functionality on a decade-old Palm design compared to what is available on all of the Nokia phones I've looked at, the WinCE phones/PDA's, the N800, etc. So I want Palm as a company to stick around. But with Treo getting eclipsed by newer smart phones, and the Foleo not getting particularly good buzz by folks reviewing it --- and after I played with it, I have to agree with the majority of the reviewers that this is not the Next Big Thing --- I'm not sure how much longer Palm is going to be around.

Daddy, What's Internet Explorer?

... and you want to preserve Internet Radio, please consider calling your representative.

Ted Ts'o had an interesting post about git recently. He has a lot of good thoughts on the subject. He comments that he wound up using git because it's so Unixy (with its small commands to do things), that he sees the git community developing innovations faster than Mercurial, and that they are working to improve the documentation and user interface problems.

The being so Unixy is a double-edged sword. On the one hand, it can make it easy to write shell scripts to extend Git. That itself can be a double-edged sword (think filename quoting and the like). But one doesn't have to use the shell. The other downside is that being Unixy makes it hard to run on platforms that aren't, such as Windows. So if one is working on Unix-only software (X, the kernel, e2fsprogs, etc.), there's no need to care about it. But if you're a person like me, who has Windows users using my software, or a large organization like Mozilla, it's maybe a showstopper. Of course, workarounds exist (cygwin, git-cvsserver), but none of them are particularly nice.

I think that both Git and Mercurial are working to address their shortcomings. I've chosen hg for now because it does what I need now. And because there are very nice tools to convert hg to git, and vice-versa. So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now

So following up on my bzr post, here are the things that Mercurial is great at right now:

1. Performance. Approximately even with git, occasionally faster. Nobody else can compete with these two right now.
2. Simplicity. It's almost as easy to get started as with darcs, and with recent patches, will be even closer in the future.
3. Lots of ways to interact. You can send hg bundles, which preserve all metadata (parents, hash, authors, etc), or you can send git-format email patches, or you can push and pull between repos. The email tools will shortly be able to automatically detect what patches to send. Your choice. git doesn't seem to support lossless emailing of bundles like this, and bzr doesn't make emailing of anything easy by default.
4. Merging. hg seems to be able to automatically resolve more merge conflicts than anything else, and when it can't automatically resolve them, has a nicely configurable system to let you use your choice of tool to manually resolve them.
5. Community. The Mercurial community is open and inviting, and open to new/different ideas. It seems similar to Darcs in that respect, and somewhat dissimilar to git.
6. Rebase does not trash history like it does (barring undocumented manual intervention) in git.

I've written before about Darcs, so I won't duplicate that here.

John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

The e2fsprogs package in Etch features the ext[23] resize2fs, see it in action on a mounted /usr partition:

nancy:/root# egrep usr /proc/mounts 
/dev/mapper/nancy_vg1-usr /usr ext3 rw,noatime,nodiratime,data=ordered 0 0

Now let's extend a bit that logical volume:

nancy:/root# lvextend -L+700M /dev/nancy_vg1/usr       
Extending logical volume usr to 4.68 GB
Logical volume usr successfully resized

Next easy step is to invoke resize2fs

nancy:/root# resize2fs /dev/nancy_vg1/usr 
resize2fs 1.40-WIP (14-Nov-2006)
Filesystem at /dev/nancy_vg1/usr is mounted on /usr; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/nancy_vg1/usr to 1227776 (4k) blocks.
The filesystem on /dev/nancy_vg1/usr is now 1227776 blocks long.

Update: Mika of course already blogged about ext3 online resizing. Bug #400797 is a very good reason not to use ext2resize. I remember a post from Theodore Tso on it's bad code quality. Don't trust it.